Blue Prism 6.7.1 : avril 2020

Un problème apparu dans la version 6.7.0 provoque la perte des réglages du service Windows configurés pour les services de serveur Blue Prism lors de la mise à niveau des serveurs fonctionnant sous la version 6.7.0. Ce problème concerne uniquement les déploiements de mise à niveau depuis la version 6.7.0. Il n'affecte pas les serveurs qui fonctionnent sous une version antérieure.

Si vous procédez à une mise à niveau depuis Blue Prism 6.7.0 vers cette version, veillez à noter dans les moindres détails le log existant ainsi que les autres propriétés configurées pour le service de serveur Blue Prism afin de pouvoir les appliquer à nouveau après la mise à niveau. Ce problème concerne uniquement la configuration directement appliquée au service Windows. Elle n'affecte pas la configuration appliquée par le fichier BPServer.exe.

Lors de la mise à niveau vers Blue Prism 6.7.1, toutes les fonctions de date renvoient désormais des résultats qui suivent le format de date défini sur la machine locale. Blue Prism 6.7.0 a introduit un comportement incorrect qui peut entraîner le renvoi de dates au format américain sur certaines machines alors qu'elles renvoyaient des dates au format britannique par le passé.

Le comportement introduit dans la version 6.7.0 qui exigeait que tous les clients interactifs et serveurs d'applications utilisent le même fuseau horaire UTC pour que l'option Exécuter maintenant de la salle de contrôle fonctionne a été résolu. Ce comportement est de nouveau le même que dans toutes les versions précédentes de Blue Prism. L'option Exécuter maintenant de la salle de contrôle utilise donc le fuseau horaire défini sur le client interactif initial pour déclencher les plannings. En revanche, les clients interactifs et les serveurs d'applications doivent toujours utiliser le même fuseau horaire pour que cette fonctionnalité fonctionne comme prévu.

Les pages web lancées depuis le modélisateur d'application avec Internet Explorer s'affichent désormais correctement si l'URL contient des caractères japonais. Auparavant, si l'URL contenait ce type de caractères, la page web associée ne s'affichait pas dans Internet Explorer.

Toute tentative de démarrage d'un processus dans la salle de contrôle sur une ressource d'exécution qui n'est pas connectée fait désormais apparaître un message d'erreur. Auparavant, ce scénario aboutissait à une exception non gérée.

Le message introduit par l'erreur us-5492 dans la version 6.7.0, qui indique que le logging Unicode n'est pas activé et que vous risquez de perdre des données, a été désactivé car la logique utilisée pour déterminer à quel moment ce message devait s'afficher n'était pas correcte.

Si le déploiement est utilisé pour traiter des données Unicode, nous vous recommandons de sélectionner Activer la prise en charge Unicode pour les logs de session dans les réglages système.